Separating CardReaderPaymentController's events from MultiLiveEvent

Closes: #12823

This is part 2 of 5 PRs refactoring the Payment flow:

1. [POS] Custom payment UI — Part 1 | Separating payment collection management from Android Framework
2. [POS] Custom payment UI — Part 2 | Separating CardReaderPaymentController's events from MultiLiveEvent
3. [POS] Custom Payment UI – Part 3 | Emitting UI–agnostic payment states in CardReaderPaymentController
4. [POS] Custom payment UI — Part 4 | Switch from viewStateData to paymentState
5. [POS] Custom payment UI — Part 5 | Unit tests clean up

⚠️ Don't merge — the branch will be merged together with the above ones after additional testing of the whole refactor.

Description

This PR refactors the way CardReaderPaymentController emits events:

1. CardReaderPaymentController emits now sealed class CardReaderPaymentEvent instances. This is safer to operate on a set of (sealed) classes bound to the parent class. Additionally, this removes the dependency on the MultiLiveEvent.Event and MultiLiveEvent in CardReaderPaymentController. These classes are not needed and desirable in Woo POS.
2. The existing CardReaderPaymentViewModel subscribes to the controller's events observable, maps it, and exposes in the form of the old model (extending MultiLiveEvent.Event) emitted by LiveData—retrofitting the existing UI implementation.

Testing information

As a result of the refactoring done within this PR, the app should work without any change. It's crucial to test the IPP flow in the store management and POS modes against regression. It may be useful to base on the test plan (pdfdoF-5Jz-p2).

The tests that have been performed

I tested the payment collection flow in both POS and store management modes, using card-present payment and TTP; and verified that the IPP flow works and is not changed.
Configurations:

1. CA — payment collection/refund with Stripe test card (WisePad)
2. US — payment collection/refund with Stripe test card (TTP, M2)
3. Stripe and Woo Payments plugins

• I have considered if this change warrants release notes and have added them to RELEASE-NOTES.txt if necessary. Use the "[Internal]" label for non-user-facing changes.

Reviewer (or Author, in the case of optional code reviews):

Please make sure these conditions are met before approving the PR, or request changes if the PR needs improvement:

• The PR is small and has a clear, single focus, or a valid explanation is provided in the description. If needed, please request to split it into smaller PRs.
• Ensure Adequate Unit Test Coverage: The changes are reasonably covered by unit tests or an explanation is provided in the PR description.
• Manual Testing: The author listed all the tests they ran, including smoke tests when needed (e.g., for refactorings). The reviewer confirmed that the PR works as expected on big (tablet) and small (phone) in case of UI changes, and no regressions are added.